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I.  INTRODUCTION 

This  manual  replaces  TN  25-75,  SOL-370  Language  Reference 

Manual  and  Users'  Guide.  The  syntax  description  in  this  document 
reflects  the  latest  updates  as  implemented  in  S0L-37U  Rel.  6/78. 

SOL-370  is  a dialect  of  the  SOL-simulation  language  as 
developed  by  Knuth  and  McNeley*  . The  original  SOL  language  has 
been  extended  to  accomodate  algorithms  essential  for  the 
simulation  of  communications  networks  and  systems.  Furthermore, 
SOL-370  has  been  implemented  as  an  extension  of  the  PL/I 
language.  This  allows  for  a free  intermixing  of  SOL-370  and  PL/I 
language  statements. 

SOL-370  is  an  algorithmic  language  used  to  construct  models 
of  general  systems  for  simulation  in  a readable  form.  The  model 
builder  describes  his  model  in  terms  of  PROCESSES  whose  number 
and  detail  are  completely  arbitrary  and  definable  within  the 
constraints  of  the  language  elements.  A SOL  model  consists  of  a 
number  of  statements  and  declarations  which  have  a character 
similar  to  that  found  in  programming  languages  such  as  PL/I  and 
ALGOL. 

The  model  is  not  built  to  be  executed  in  a sequential 
fashion,  as  ordinary  programming  languages  require.  Rather,  the 
processes  are  written  and  executed  as  though  all  were  running  in 
parallel.  Control  among  processes  is  maintained  by  the 
interaction  of  GLOBAL  ENTITIES  ana  by  control  and  communications 
instructions  within  the  different  processes.  At  the  initiation 
of  the  simulation  all  processes  are  begun  simultaneously. 

Variables  declared  within  a process  are  called  LOCAL 
VARIABLES.  Within  a given  process  it  is  possible  to  have  several 
actions  occurring  at  once;  therefore,  to  visualize  the  process, 
we  may  think  of  several  objects  on  which  the  action  takes  place, 
each  in  its  own  place  in  the  process  at  any  given  time.  These 
objects  will  be  referred  to  as  TRANSACTIONS.  A set  of  local 
variables  corresponding  in  number  to  those  declared  in  the 
process  is  "carried  with"  each  transaction  of  that  process. 
Transactions  situated  within  one  process  may  not  refer  to  the 
local  variables  of  another  process  nor  to  the  local  variables  of 
another  transaction  in  the  same  process. 

GLOBAL  ENTITIES  are  of  four  major  types:  GLOBAL  VARIABLES, 
FACILITIES,  STORES,  and  TRUNKS.  Global  variables  can  be 
referenced  or  changed  by  any  transaction  from  any  process  in  the 
system,  and  the  variable  possesses  only  one  value  at  any  given 
time. 


* l).  E.  Knuth  ana  J.  L.  McNeley^  "A  Formal  Definition  of 
SOL,"  IEEE  Transactions  on  Electronic  Computers,  EC-13 
No.  5 (Aug  1964)  pp  4U9-414 
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1.  THE  SYNTAX  NOTATION 

The  Backus  Normal  Form  (BNF)  Is  used  to  describe  the  syntax 
of  the  SOL  language.  The  following  rules  explain  the  use  of  this 
notation. 

a.  The  Notation  Variable.  A Notation  Variable  Is  the  name 
for  a class  of  elements  used  In  a programming  language.  It 
consists  of  letters  and  typhens  and  is  enclosed  in  "less  than" 
and  "greater  than"  symbols. 

EXAMPLES: 

<digit>  This  denotes  the  occurrence  of  a digit,  which  may 
assume  a value  within  the  range  of  0 through  9. 

<facility  name>  This  denotes  the  occurrence  of  a Notation 
Variable  of  the  class  Facility  Name. 

<do  statement  This  denotes  the  occurrence  of  a DO 
statement. 

b.  The  Notation  Constant.  A Notation  Constant  is  the 
literal  occurance  of  a string  of  characters.  It  is  represented 
in  capital  letters. 

Exampl e: 

STORE  This  denotes  the  literal  occurrence  of  the  word 
"STORE". 

c.  The  Syntactical  Unit.  A Syntactical  Unit  is  defined 
as  a single  variable,  a constant,  or  any  collection  of  notation 
variables,  notation  constants,  and  syntax  language  symbols.  The 
vertical  stroke  "I"  separating  two  Syntactical  Units  indicates  a 
choice,  which  can  be  made  between  the  two.  Anything  enclosed  in 
brackets  denotes  an  option.  The  syntax  within  the  brackets  may 
be  used  or  left  out. 

EXAMPLES: 

<identifier>  FIXED | FLOAT  This  denotes  an  identifier  which 

may  have  the  attribute  FIXED  or 
FLOAT. 

<iaentifier>[(<constant>)]  This  denotes  an  identifier  which 

may  optionally  be  subscripted  by 
a number. 
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d.  General  Format.  The  syntax  statement  is  composed  of 
a notation  variable  separated  from  the  following  syntactical  unit 
by  the  definition  symbol  . 


EXAMPLE: 

<go  to  statement  GO  TO  <label>; 


THE  MODEL  STRUCTURE 

When  coding  a SOL  model  the  format  below  should  be  followed: 


<global  variable  declarat1ons> 
<resource  declarations> 

<table  declarat1ons> 

<process  declaration> 

<process  statements> 

<end  statement> 

<process  declaration> 

<process  statements> 

<end  statement> 


<end  statement> 


GLOBAL  DECLARATIONS 


FIRST  PROCESS 


SECOND  PROCESS 


MODEL 


First,  all  global  declarations  should  be  listed.  The  order 
of  the  global  declarations  is  arbitrary.  The  oraer  in  which 
processes  are  listed  should  be  selected  carefully,  since  the 

first  process  will  be  started  first  and  if  any  values  are  read 

for  global  variable  initialization,  this  should  be  done  in  the 
first  process.  The  program  should  be  followed  by  an  END 

statement.  If  not  included,  the  system  will  provide  this 

statement. 


a.  Process  Declaration 

<process  descriptions :=PR0CESS  <identifier> 

[,T=<constant>]  [ ,R=<constant>]; 

Each  process  is  bracketed  with  the  process  declaration  and 
an  END  statement.  The  two  optional  parameters  allow  the  modeler 
to  specify  the  maximum  number  of  simultaneous  transactions  T and 
the  maximum  number  of  resources  R (facilities,  stores,  and 
trunks)  encountered  by  any  one  transaction.  This  feature  is 
important  in  optimizing  the  model's  core  requirements. 

EXAMPLE: 


PROCESS  SWITCH,  T=luU,  R=4; 
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b.  Variable  Declaration.  Variables  are  declared  either  at 
the  beginning  of  the  program  outside  the  processes  as  GLOBAL 
VARIABLES,  or  at  the  beginning  of  each  process  as  LOCAL 
VARIABLES. 

<global  variable  declaration>:=<variable  declaration> 

<variable  declaration>:=INTEGER  <identffier  list>  ; 

I REAL  identifier  1 i st> ; 

. When  declared  INTEGER,  their  internal  representation  will  be 

fixed  binary;  when  declared  REAL,  floating  decimal. 

EXAMPLES: 

INTEGER  A,  B,  C,  D; 

REAL  X,  Y,  Z; 

INTEGER  AR (16); 

INTEGER  BAR (0:100); 


c.  Resource  Declarations 

<resource  declaration>  ::=  <facility  declarations 

I <store  declarations 
I <trunk  declarations 

All  resources  must  be  declared  ahead  of  the  process  declarations. 
For  details  see  the  discussion  for  the  specific  resource. 

3.  IDENTIFIERS  AND  CONSTANTS 

<letter>: :=A|B|C|D| ... |Z 

< digits : =0|1|2|3| ... |9 

<constant>: :=<constant> |<decimal  constant> 

<constant>: :=<digit> 

<time>::=  - I + 

<decimal  constants :=<constant>.<constant>[E<sign><constant>] 
<i denti f i er> : : =<1 etter> I <i denti f i er>  <1 etter> I 
<letter><digit> 

Specific  identifiers  are  usea  as  the  names  of  global 
variables,  resources,  statistical  tables,  processes,  and 
procedures.  A specific  identifier  can  be  used  for  only  one 
purpose  in  a program.  Constants  are  used  to  represent  integer 
numbers;  decimal  constants  represent  real  numbers.  Identifiers 
must  be  declarec  before  they  are  used  elsewhere.  All  SOL 
commands  ana  variables  starting  with  are  reserved  woras  and 
should  not  be  used  as  identifiers. 
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4.  EXPRESSIONS  AND  RELATIONS 


<name> : : =<i dentl f i er> I < i denti f i er> \ ( <expressi on> ) 

By  variable  name,  facility  name,  etc.,  we  will  mean  that  the 
identifier  in  the  name  has  appeared  in  a variable  declaration, 
facility  declaration,  etc.,  respectively. 

<primary>: :=<variable  name> |<store  name>| 

<constant> I <decimal  constant> I TIME | 
(<expression>) |ABS(<expression>) | 

DISTRIBUTION! (a)x,(b)y,...(c)z)| 

NORMAL ( <expressi on> , <expressi on> ) I 
EXPONENTIAL ( <expressi on> ) | POISSON ( <expressi on> ) | 
GEOMETRIC! <expression> ) I RANDOM 
< term> : : = <p ri ma ry>  i < term>  < p ri ma ry > I < term> , <p ri ma ry > | 
MOD(<term>,<primary> ) 

<sum> : :=<term> I +<term> I -<term> | <sum>+<term> I <sum>-<term> 
<unconditional  expression>: :=<sum> I <aigit>: <digit> 
<expression>: :=<unconditional  expression>  I 

if  <relation>  THEN  <expression>  ELSE  <expression> 

The  meaning  of  an  arithmetical  operation  inside  an 
expression  is  identical  to  the  meaning  in  PL/1. 

The  new  elements  here  are  "M0D(a,b),“  the  positive  remainder 

obtained  upon  dividing  a by  b ; "MAX(a,b,c, )"  and 

"MIN(a,b,c,...),"  which  denote  the  maximum  and  minimum  values, 
respectively,  of  the  expressions  in  parentheses;  and  there  are 
also  notations  for  expressing  random  values.  The  expression 
DISTRIBUTION  ( (a)x,{b)y,. . . (c)z) ) indicates  a random  selection 
between  integers  x,  y,  and  z with  the  respective  weights  a,b,  and 
c. 

EXAMPLE  : 

A=DISTRIBUTION( !4) 1,(2 )2,( 3)4, (9)9); 

The  expressions  NORMAL (M,S ) , POISSON(M),  GEOMETRIC(M) , and 
EXPONENTIAL(M)  indicate  random  values  with  special  distributions 
which  occur  frequently  in  applications.  A random  number  drawn 
from  the  normal  distribution  with  mean  M and  standard  deviation  S 
is  denoted  by  NORMAL (M,S)  and  is  a real  (not  necessarily  integer) 
value.  A number  drawn  from  the  exponential  distribution  with 
mean  M is  denoted  by  EXPONENTIAL(M)  and  is  also  of  type  real. 
The  poisson  distribution  signified  by  POISSON  (M) , on  the  other 
hand,  yields  only  integer  values;  e.g.  the  probability  that 
POISSON(M)  = n is  (e'MMn/n!).  The  geometric  distribution  with 
mean  M,  aenoted  by  GEOMETRIC(M) , also  yields  integer 
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values,  where  the  probability  that  GEOMETRIC (M)=N-1  is 
1/M(1-1/M).  The  symbol  RANDOM  denotes  a random  real  number 
between  0 and  1 having  a uniform  distribution.  Finally, the 
notation  a:b  denotes  a random  integer  between  the  limits  a and  b. 
The  normal,  exponential,  poisson,  and  geometric  distributions  are 
mathematically  expressible  in  terms  of  random  distributions  as 
f ol 1 ows : 

NORMAL(M.S)  = S * v^^TTnTIAHlJDRT  * sin(2n*RAND0M)  + M 

EXPONENTIAL(M)  = - M 1 n( RANDOM) 

POISSON(M)  = n if  e'*(l+M+Mx/2 !+ +Mn'‘/(n-l)!) 

<=  RANDOM  < e-"(l+M  + ...  +Mn/n!) 

GEOMETRIC  (Ni)  = {1  + 1 n(RANDOM) /I  n(  1-1/M) ) . 

As  examples  of  the  use  of  these  distributions,  consider  a 
population  of  customers  coming  to  a market  with  an  average  of  one 
customer  every  M minutes.  The  distribution  of  waiting  time 
between  successive  arrivals  is  EXPONENTIAL (M) . On  the  other 
hand,  if  an  average  of  M customers  come  in  per  hour,  the 
distribution  of  the  actual  number  of  customers  arriving  in  a 
given  hour  is  POISSON(M).  If  an  individual  performs  an 
experiment  repeatedly  with  a chance  of  success,  I/M,  on  each 
independent  trial,  the  number  of  trials  needed  until  he  first 
succeeds  is  GEOMETRIC (M) . 

The  special  symbol  "TIME"  indicates  the  current  time; 
initially,  time  is  zero.  The  value  of  a store  name  is  the 
capacity  remaining  in  the  store. 

Relational  operator>  : | ,s  I <s  I >s  I > I < 

Relation  primary>::=  Unconditional  expression> 

Relational  operator>  unconditional  expression^ 
<facility  name>  BUSY  I < f ac i 1 i ty  name>  NOT  BUSY  | 
<store  name>  FULL  | <store  name>  NOT  FULL  | 

<store  name>  EMPTY  | <store  name>  NOT  EMPTY  I 
PROBABILITY  <expression>  | (<relation>) 
<relation>  ::=  Relation  primary>| 

Relation  primary>  I Relation  primary>| 

Relation  primary>  4 <relation  primary>| 
"'Relation  primary> 

These  relations  have  obvious  meanings  except  for  the 
construction  "PROBABILITY  e ,"  which  stands  for  a random 
condition  that  is  true  with  probability  e.  (Here  e must  be  less 
than  or  equal  to  1. ) 

IF  PROBABILITY  U.12  THEN{12%  of  the  time)  ELSE(88%  of  the  time). 
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5.  FACILITIES  AND  ASSOCIATED  COMMANDS 


A FACILITY  is  a global  element  which  can  be  controlled  by 
only  one  transaction  at  a time.  Associated  with  each  request  for 
the  facility  is  a “control  strength,"  and  if  a requesting 
transaction  has  a higher  strength  than  the  transaction 
controlling  the  facility,  an  interrupt  will  occur.  Interrupts 
may  be  nested  to  any  depth.  If  the  requesting  transaction  is  not 
of  greater  strength  than  the  controlling  transaction,  then  the 
requesting  transaction  stops  and  waits  for  the  facility  until  the 
controlling  transaction  releases  its  control. 

The  following  declarations  and  commands  are  associated 
with  facilities. 

a.  Facility  Declaration 

<facility  declaration?  ::=  FACILITY  <facility  name  list?; 
<facility  name  list?: :=<facility  name?[,<facil ity  name  list?] 
<facility  name>::=  <name?[(<constant? )] 

Facilities  are  declared  at  the  beginning  of  the  program  ahead  of 
the  processes.  Facilities  may  be  declared  as  one-dimensional 
arrays. 

EXAMPLES:  FACILITY  TERMINAL; 

FACILITY  LINE  (16); 

b.  SEIZE  Statements 

<seize  statement?: :=  SEIZE  <facility  name?; I 

SEIZE  <facility  name?,  expression?; 

The  first  form  is  equivalent  to  "SEIZE  <facility  name?,  0."  This 
statement  is  usually  rather  simple,  but  there  are  situations  when 
complications  arise.  If  the  facility  is  not  busy  when  this 
statement  occurs,  then  it  becomes  busy  at  this  point  and  remains 
busy  until  later  released  by  this  transaction.  (Note:  If  this 
transaction  creates  another  transaction,  the  new  transaction  does 
not  control  the  facility.)  The  Expression?  in  the  SEIZE 
statement  represents  the  "control  strength"  which  is  normally 
zero.  Allowance  is  made,  however,  for  one  transaction  to 
interrupt  another.  For  example,  if  the  facility  is  busy  when  the 
seize  statement  occurs,  let  CS  be  the  control  strength  with  which 
the  facility  was  seized  and  let  HS  De  the  control  strength  of 
this  seize  statement.  If  HS  <=  CS  , the  transaction  executing 
the  SEIZE  statement  waits  until  the  facility  is  not  busy.  If  HS 
? CS  , however,  interrupt  occurs.  The  preempted  transaction  is 
handled  according  to  the  last  INTERRUPT  statement  it  executed. 
The  transaction.  A,  wliich  had  control  of  the  facility,  is  stopped 
wherever  it  was  in  its  process,  and  the  present  transaction,  B, 
seizes  the  facility.  When  B releases  the  facility,  the  following 
occurs: 
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(1)  If  A was  executing  a wait  statement  when 
interrupted,  the  time  of  wait  is  increasea  by  the  time  which 
passed  during  the  interrupt. 

(2)  There  may  be  several  transactions  waiting  but  not 
attempting  to  seize  this  facility.  If  any  of  these  has  a higher 
control  strength  than  CS,  then  A is  interrupted  again.  The 
transaction  whicn  interrupts  is  chosen  by  the  normal  rules  for 
deciding  who  obtains  control  of  a facility  upon  release,  as 
described  in  the  section  for  the  RELEASE  STATEMENT. 

The  control  strength  in  the  present  Implementation  of  SOL 
must  be  an  integer  between  0 and  15.  This  allows  Interrupts  to 
be  nested  up  to  15  deep. 

EXAMPLES: 

% 

SEIZE  TERMINAL,  PRIOR ITYCLASS; 

SEIZE  LINE,  10; 

SEIZE  PUMP; 

SEIZE  TERMINAL,  1:10; 

SEIZE  LINE,  EXPONENTIAL (15); 

SEIZE  LINE,  A*(B-C); 

c.  RELEASE  Statement 


<release  statements :=RELEASE  <facility  name>; 

This  statement  is  permitted  only  when  the  transaction  is 
actually  controlling  the  facility  because  of  a previous  seizure. 
When  the  facility  is  released,  there  may  be  several  other 
transactions  waiting  because  of  seize  statements.  In  this  case, 
the  one  which  gets  control  of  the  facility  next  is  chosen  by 
consideration  of  the  following  three  quantities  in  order: 

(1)  Highest  control  strength 

(2)  Highest  PRIORITY 

(3)  First  to  request  the  facility. 

EXAMPLES: 

RELEASE  TERMINAL; 

RELEASE  LINE; 

RELEASE  PUMP; 
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d.  Testing  the  Status  of  a Facility 

facility  status>  BUSY  | NOT  BUSY 

The  status  of  a facility  can  be  tested  for  the  condition  BUSY 
or  NOT  BUSY.  The  facility  status  can  be  used  In  any 
compound  statement  as  a relation  primary. 

EXAMPLES: 

IF  TERMINAL  BUSY  THEN  CANCEL; 

IF  LINE  NOT  BUSY  THEN  GO  TO  LOAD; 

WAIT  UNTIL  TERMINAL  NOT  BUSY; 

6.  STORES  AND  ASSOCIATED  COMMANDS 

STORES  are  space-shared  rather  than  time-shared  global 
elements  and  they  are  assigned  a specific  storage  capacity.  As 
long  as  there  is  sufficient  storage  to  accommodate  the  requesting 
transaction  the  request  for  space  is  satisfied;  otherwise,  the 
transaction  waits  for  the  space.  A facility  may  be  regarded  as  a 
store  which  has  a capacity  of  one  unit  only,  except  for  the  fact 
that  no  interrupt  capability  is  provided  for  stores. 

The  following  declarations  and  control  statements  are 
associated  with  manipulating  stores: 

a.  STORE  Declaration 

<store  declaration>  ::=STORE  <store  list>; 

<store  list>  ::=  <capacity>  <store  name>[ ,<store  list>] 
<store  name>  ::=  <name>[(<constant> )] 

<capacity>  ::=  <constant> 

STORES  are  declared  at  the  beginning  of  the  program  ahead  of  the 
processes.  STORES  may  be  aeclared  as  one-dimensional  arrays. 

EXAMPLES:  STORE  10  STACK; 

STORE  512  CORE,  10  BUFFER (5); 

b.  ENTER  Statement 

<enter  statements : = ENTER  <store  name>;| 

ENTER  <store  name>,  <expression>; 

The  first  form  is  an  abbreviation  for  "ENTER  <store  name>, 
1."  The  value  of  the  expression  is  truncated  and  represents  the 
number  of  units  requested  of  the  store.  The  transaction  will 
remain  at  this  statement  until  that  number  of  units  becomes 
available  and  until  all  other  transactions  of  greater  or  equal 
priority  which  have  been  waiting  for  storage  space  have  been 
serviced. 
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EXAMPLES: 


ENTER  STACK; 

ENTER  CORE,  2S6; 

ENTER  CORE,  BYTE  * LENGTH; 

c.  LEAVE  Statement 

<leave  statement  ::=  LEAVE  <store  name>  ; I 

LEAVE  <store  name>,<expression>; 

The  first  form  is  an  abbreviation  for  "LEAVE  <store  name>,  1." 
This  statement  returns  the  number  of  units  equivalent  to  the 
value  of  the  (truncated)  expression. 

EXAMPLES: 

LEAVE  STACK; 

LEAVE  CORE,  128; 

LEAVE  BUFFER  (NODE),  LENGTH; 

d.  Testing  the  Status  of  a Store 

<store  status>  = FULL  I NOT  FULL  I EMPTY  | NOT  EMPTY; 

The  status  of  a store  can  be  tested  for  the  following  conditions: 

FULL,  NOT  FULL,  EMPTY,  NOT  EMPTY. 

In  combination  with  other  SOL  or  PL/I  statements  a variety  of 
compound  statements  may  result. 

EXAMPLES: 

IF  SWITCH  FULL  THEN  WAIT  PAUSE; 

IF  SWITCH  NOT  FULL  THEN  ENTER  SWITCH; 

7.  TRUNKS  AND  ASSOCIATED  COMMANDS 

TRUNKS  are  space-shared  global  elements  similar  to  STORES. 
However,  in  contrast  to  stores,  trunks  allow  for  preemption.  As 
long  a s there  is  sufficient  storage  to  accommodate  the  requesting 
transaction,  the  request  for  space  is  satisfied  without  further 
action.  Each  transaction  holding  space  in  a trunk  is  assigned  a 
specific  holding  strength,  which  may  be  different  from  the 
preemption  strength.  Thus,  a transaction  with  a low  preemption 
strength  once  assigned  space  in  a trunk  can  have  a very  high 
holding  strength;  therefore,  preemption  of  it  becomes  unlikely. 
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a.  TRUNK  Declaration 


<trunk  declarations :=TRUNK  <trunk  1 1st> ; 

<trunk  list>::=  <capacity>  <trunk  name>[,<trunk  11st>] 
<trunk  name>::=  <name>[(<ceostant>)] 

TRUNKS  are  declared  at  the  beginning  of  the  program  ahead  of  the 
processes.  TRUNKS  may  be  declared  as  one-dimensional  arrays. 
All  elements  of  a TRUNK  array  assume  the  same  capacity  value. 

EXAMPLES: 

TRUNK  96  SWITCH (16) ; 

TRUNK  1000  CORE; 

b.  DEMAND  Statement 

<demand  statements :=  DEMAND  <trunk  name>,  <capac1ty>, 

< demand  strengths  <hold  strengths 
<trunk  name>::=  <name>[(<constant> )]  |<name>(<var1ab'ie>) 

The  demand  statement  Is  a request  for  a number  of  units  of  a 

trunk.  If  the  units  requested  are  available  In  the  trunk,  they 

are  assigned  to  the  transaction.  Associated  with  the  resource 

allocation  is  the  hold  strength  specified  in  the  demand 

statement. 

If  the  required  number  of  units  is  not  available,  then  the 
following  takes  place: 

(1)  The  number  of  units  needed  through  preemption  is 
calculated. 

(2)  The  sum  of  the  space  held  by  other  transactions  at 
a hold  strength  less  than  demand  strength  of  the  demanding 
transaction  is  determined. 

(3)  If  the  total  available  and  preemptable  space  is 
sufficient  to  satisfy  the  demand,  transactions  are  preempted  as 
required  to  free  enough  space.  The  demanding  transaction  is  then 
allocated  the  space  with  the  associated  hold  strength  and 
continues  in  sequence.  Note  that  the  interrupted  transactions 
are  handled  according  to  the  setting  of  their  interrupt  action 
indicator. 

(4)  If  there  is  not  enough  preemptable  space  in  the 
trunk,  the  transaction  is  queued  up  on  demand  strength. 

EXAMPLES: 

DEMAND  LINK (15),  TRANSM_RATE , 4,  10; 

DEMAND  CORE (NODE) , 512,  A,  (A  + C)/B; 


c.  YIELD  Statement 


<yield  statement  YIELD  <trunk  name>  , <capacity>, 

<hold  strengths 

<trunk  name>  <name>[(<constant>)]  |<name>(<variable>) 

The  yield  statement  releases  the  specified  number  of  units  in 
the  trunk  at  the  specified  hold  strength.  If  the  number  to  be 
released  is  greater  than  the  number  currently  held  by  the 
transaction  at  that  hold  strength,  the  simulation  terminates  with 
an  error.. 

EXAMPLES:  YIELD  LINES(5),  40U,  10; 

d.  CAPACITY  Function 

<primary>: :=CAPACITY  (<trunk  name>,  <demand  strength>) 

The  capacity  function  is  provided  to  test  the  status  of  a 
trunk.  The  capacity  function  returns  the  number  of  units 

available  for  a demand  of  the  capacity  of  the  specified  demand 
strength.  No  resources  are  allocated  and  the  current  state  of 
the  trunk  is  not  touched.  This  function  allows  the  simulation  to 
interrogate  the  state  of  the  trunk  prior  to  attempting  a demand 
statement  upon  it. 

8.  TRANSACTIONS  AND  ASSOCIATED  STATEMENTS 

Transactions  represent  aiscrete  elements  "flowing"  through 
the  model.  They  are  local  to  a particular  process  and  may  have  a 

number  of  descriptors  (local  variables).  For  example,  in  a road 

network  simulation  a transaction  may  represent  individual 

vehicles.  The  properties  of  these  vehicles,  such  as  speed, 
number  of  passengers,  fuel  consumption,  etc.,  are  described  by 
the  local  variables.  Each  transaction  has  its  own  set  of 
local  variaDles.  The  following  statements  directly  control  the 
creation,  disappearance,  queuing,  or  transfer  of  transactions. 

a.  Creation  of  Transactions.  At  the  beginning  of 
simulation  there  is  one  transaction  present  for  each 
process  described.  Each  of  these  initial  transactions 
starts  at  time  zero  and  is  positioned  at  the  beginning  of 
the  process.  More  transactions  may  be  created  by  using  "start 
statements." 

<start  statements :=  NEW  TRANSACTION  TO  < 1 abel > ; 

This  statement,  when  executed,  creates  a new  transaction  (whose 
local  variables  are  the  same  in  number  and  value  as  those  of  the 
transaction  which  created  it).  The  new  transaction  begins 
executing  the  program  at  label  while  the  original  transaction 
continues  in  sequence. 
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b.  Disappearance  of  Transactions.  Transactions  "die"  when 
they  execute  a cancel  statement. 

<cancel  statement : : =CANCEL ; 

An  implied  cancel  statement  is  at  the  end  of  every  process,  so 
cancel  statements  need  not  always  be  explicitly 
written.  Transactions  are  also  cancelled  when  they  are  preempted 
ana  the  global  variable  INTERRUPT  has  been  set  to  CANCEL  (see 
discussion  of  'Interrupt'). 

c.  Queuing  Of  Transactions.  Whenever  a transaction 
encounters  a blocked  resource  such  as  a full  store,  a busy 
facility  or  a full  trunk.  It  automatically  enters  the  queue 
associated  with  this  resource.  Besides  these  situations  the 
following  wait  conditions  may  be  programmed  for: 

(1)  WAIT  Statements 

<wait  statements :=WAIT  <expression>; 

The  expression  is  truncated  , and  then 
this  statement  advances  "TIME"  by  MAX(0,<expression>) , as  far  as 
this  transaction  is  concerned.  All  time  delays  In  a simulated 
process  are,  in  the  last  analysis,  specified  by  using  wait 
statements. 

EXAMPLES: 

WAIT  4UU; 

WAIT  SIMULATION_TIME; 

WAIT  (A  + B)/C; 

(2)  WAIT  UNTIL  Statements 

<wait-until  statements :=WAIT  UNTIL  <relation>; 

This  causes  the  transaction  to  freeze  at  this  point  until 
the  <relation>  becomes  true  (because  of  action  by  other 
transactions).  The  relation  must  not  involve  expressions  which 
have  a random  value;  e.g.,  it  is  not  legal  to  write  "WAIT  UNTIL 
PROBABILITY  10"  or  "WAIT  UNTIL  A = 1:4  ,"  etc. 

EXAMPLES: 

WAIT  UNTIL  SWITCH  EMPTY; 

WAIT  UNTIL  TIME  > SIMULATION  TIME; 


I 
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d . Transfer  Of  Transacti ons 

( 1 ) GO  TO  Statements 

<go  to  statement>  GO  TO  <label>; 

This  statement  is  used  to  transfer  to  another  point  in  the 
program;,  statements  are  usually  executed  sequentially. 

( 2 ) INTERRUPT  Statement 

INTERRUPT  = WAIT ; I CANCEL ; I <1 abel > ; 

INTERRUPT  is  a glooal  variable  which  specifies  the  action  to 
be  taken  for  a preempted  transaction.  Whenever  the  interrupt 
variable  has  been  set,  the  action  for  all  subsequent  preemptions 
any  place  within  the  program  is  specified  unless  the  interrupt 
variable  is  reset. 


INTERRUPT  = WAIT; 

If  the  interrupted  transaction  is  executing  a WAIT  statement 
when  interrupted,  the  wait  time  is  increased  by  the  time  which 
passed  during  the  interrupt.  If  the  interrupted  transaction  was 
executing  anything  other  than  a WAIT,  the  transaction  is 
cancelled. 

INTERRUPT  = CANCEL; 

The  interrupted  transaction  is  unconditionally  cancelled. 
(Refer  to  cancel  statement). 

INTERRUPT  = <1 abel > ; 

The  interrupted  transaction  is  started  immediately  at  the 
statement  specified  by  label  and  the  transaction  no  longer 
controls  the  preempted  facility. 

9.  SPECIAL  SOL  STATEMENTS 

a.  PRIORITY  Statement.  If  by  coincidence  two  transactions 
attempt  to  3o  something  at  precisely  the  same  time,  they  may 
be  in  conflict;  that  is,  they  may  both  want  to  seize  a facility, 
to  change  the  value  of  the  same  glooal  variable,  or  one 
may  want  to  change  it  while  the  other  is  using  its  value. 
Actually,  in  such  cases  of  conflict,  the  simulator  does 
choose  a specific  oraer  for  execution;  no  two  things  actually 
happen  at  the  same  instant,  as  we  deal  more  properly  with 
infinitesimal  differences  of  time  between  the  discrete  units. 
The  choice  of  order  is  fairly  arbitrary  except  when  a 
difference  of  priority  is  specified;  in  that  case,  the 
transaction  with  higher  priority  (lower  value)  will  be 
acted  on  first.  Each  transaction  has  a priority,  which  is 
initially  zero;  priority  is  changed  by  the  statement 


PRIORITY  = <expression>; 


The  declaration  "integer  PRIORITY"  is  implied  at  the 
beginning  of  each  process;  i.e.,  PRIORITY  is  treated  as  a local 
variable.  In  the  present  implementation  of  SOL,  the  priority 
must  be  between  0 and  15. 

b.  STOP  Statement 


<stop  statement  STOP; 

A stop  statement  causes  simulation  to  terminate  immediately, 
and  all  transactions  cease. 

c.  Checkpoint  - Restart 

(1)  The  BREAKOUT  Statement.  For  long  simulation 
runs  it  becomes  necessary  to  program  checkpoints  to  save 
intermediate  results  for  possible  later  restarts.  Checkpoint 
data  are  saved  whenever  a BREAKOUT  statement  is  executed. 

<breakout  statement  ::=  BREAKOUT  TO  <label>; 

If  a label  is  specified,  the  transaction  executing  the 
breakout  statement  will  be  restarted  at  this  label  at  restart 
time,  but  will  continue  its  execution  after  a checkpoint  in 
regular  fashion.  Checkpoints  are  numbered  sequentially  and  the 
simulation  may  be  restarted  at  any  of  them.  The  PARM 
parameter  in  the  execution  card  is  used  to  specify  the  restart 
point. 


(2)  The  RESTART  Statement.  The  restart  statement  serves 
to  save  values  of  variables  not  declared  within  the  SOL  syntax. 
In  this  way,  values  of  regular  PL/1  variables  declared  with 
a PL/1  declare  statement  may  also  be  saved  at  a checkpoint. 

<restart  statement  ::=  RESTART  <variable  list>; 

The  variable  list  contains  only  the  names  of  PL/1  variables 
and  not  the  dimensions  of  variable  arrays. 


EXAMPLE: 

DCL  (A,B,C,D)  FIXED  BIN(15), 
E ( 5 ) BITI3), 

F(0 : 100,0: 2 ) FLOAT  DEC; 

RESTART  A,B,C,D,E,F; 
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d.  Collection  of  Histogram  Data.  The  tabulate  statement  in 
conjunction ' with  the  table  declaration  is  the  vehicle  for 
collecting  data  to  be  displayed  in  histogram  format. 

( 1 ) TABLE  Dec] aration 

<min>  ::=  <constant> 

<inc>  <constant> 

<max>  <constant> 

<table  declaration>  ::= 

TABLE(<min>  BY  <inc>  TO  <max>)  <table  name>(<constant>); 

The  table  is  used  in  conjunction  with  the  TABULATE  statement 
to  collect  data  for  histographical  representation.  The  histogram 
can  be  specified  by  its  dimensions,  min,  inc,  max. 

EXAMPLE:  TABLE  (0  BY  100  TO  1U00)  TIMETABLE (5)  ; 

(2)  TABULATE  Statements 

<tabulate  statements : “TABULATE  <expression>  IN  <table  name>; 

The  value  of  the  expression  is  recorded  as  a statistical 
observation  in  the  table  specified. 

EXAMPLES:  TABULATE  (STARTIME-TIME)  IN  DIFFTABLE; 

TABULATE  TIME  IN  TIMETABLE; 

10.  COMPOUND  AND  CONDITIONAL  STATEMENTS 

Both  of  those  statements  are  legal  in  SOL  as  well  as  in 
PL/I.  Because  of  their  relative  importance  and  frequent  use, 
they  are  listed  separately. 

a.  Compound  Statements  Several  statements  may  be  combined 
into  one,  as  follows: 

statement  1 ist>:  :=<statement>;  [ statement  1 i s t> ] ; 
<compound  statements  :=BEGIN  statement  list>  END ; | 
(statement  list>) 

d.  Conditional  Statement 

<condition>: :=  IF  <relation>  THEN  <statement>; I 

IF  <relation>  THEN  <unconditional  statement  ELSE  <statement>; 


III.  SAMPLE  MODELS 


This  section  contains  a description  of  nine  sample  models. 
Including  listings  of  the  source  language  code.  Most  listings 
are  self-descriptive.  However,  a more  detailed  explanation  has 
been  provided  for  MODEL  IE. 


1.  MODEL  1A:  Single  Server  Queuing  Model  With  Constant  Arrival 
Rate. 

CARDS 

v FACILITY 


INTERNAL  CARD  .’  NONBLOCKING 

CARD  QUEUE  TRANSMITTER  TRANSMISSION  LINE > 


PROBLEM:  Punched  cards  are  arriving  at  a card  transmitter 
station  with  a constant  interarrival  interval  of  36 
seconds.  The  transmitter  can  handle  only  one  card  at  a 

time  and  needs  4U  seconds  to  process  one  card.  The 
simulation  is  to  stop  after  5 minutes. 

2.  MODEL  IB:  Single  Server  Queuing  Model  with  Poisson 
Distributed  Arrivals. 

PROBLEM:  As  in  Model  1A,  except  punched  cards  are  arriving 
polsson  distributed  with  an  average  arrival  rate  of  100 
cards/minute. 


3.  MODEL  1C:  Single  Server  Model  with  Parameterized  Input. 

PROBLEM:  Same  as  in  IB,  except  time  constants  are  to  be 
replaced  by  variables  which  are  to  be  assigned  values  from  a data 
set. 

4.  MODEL  ID:  Single  Server  Queuing  Model  with  Priority 


IB 


PROBLEM:  Same  as  in  1C,  except  cards  are  assigned 

priorities  between  1 and  8 on  a random  basis.  The 
transmitter  is  to  select  cards  from  the  input  queue  according  to 
its  priority  strength.  A message  is  to  be  printed,  when  card  is 
received. 

5.  MODEL  IE:  Single  Server  Queuing  Model  with  Preemption. 

PROBLEM:  Same  as  in  10,  except  preempt  levels  between  1 to  4 
are  to  be  assigned  randomly.  The  preempted  messages  are  to  be 
cancelled  after  a message  has  been  printed. 

6.  MODEL  IF:  Single  Server  Queuing  Model  with  External  Queue 

CARDS—. 

v 

! EXTERNAL  ’. — >!  CARD  ! — NON-BLOCKING > 

. CARD  QUEUE  . . TRANSMITTER  . TRANSMISSION  LINE 


PROBLEM:  Same  as  in  IE,  except  the  STORE  resource  'QUEUE'  is 
used  to  model  a physical  queue  ahead  of  the  transmitter. 
This  QUEUE  is  used  to  monitor  the  queue  buildup  during 

the  simulation,  since  the  internal  queue  of  the  facility  is  not 
accessible  to  the  user.  Furthermore,  a separate  process 
'CONTROL'  is  used  to  read  in  variable  values  and  control 

the  length  of  the  simulation. 

7.  MODEL  1G:  Network  fooael  - S Nodes  Fully  Connected,  but 
Nonblocxing  Links. 

PROBLEM:  Each  node  is  modeled  as  a combination  of  a 

card  transmitter  as  described  in  1G  and  a card  receiver  of 
a similar  type.  The  network  is  fully  connected  and 
nonblocking.  The  originating  nodes  and  the  terminating  nodes  are 
picked  at  random.  Each  message  is  to  be  assigned  an 

identification  number. 

8.  MODEL  1H:  Network  Model  with  Blocking  Links. 

PROBLEM:  Same  as  in  1G  except  that  blocking  on  links 
is  considered.  All  links  are  to  have  eight  channels.  No 

alternate  routing  will  be  considered.  The  connecting 
matrix  'CONN'  provides  for  cross-reference  between  nodes 
and  links. 
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9.  MODEL  II:  Network  Model  with  Alternate  Routing. 

PROBLEM:  Same  as  in  1H.  Network  has  the  following  connectivity 
(Links  are  numbered  from  1 to  7): 


1 

(1) (2) 

• • • • 

.2  4. 

!3  ’ (3)  * !5 

• • • 

.6 

(4) !.(b) 
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The  alternate  routing  will  be  of  the  following  type: 

Each  node  has  a primary  plus  two  alternate  next  nodes  to 
choose  from  for  routing  a message.  The  selection  will  simply  oe 
based  on  the  blocking  of  the  links.  The  modeler  may  assume  that 
the  routing  algorithm  has  been  precoded  as  a function  named 
'ROUTE'  with  two  arguments  representing  the  current  node  and  the 
destination  node. 

<var1able>=  ROUTE  (<orig.  node>,<term.  node>); 

The  function  will  return  the  next  tandem  node  number  of  the 
value  'O'  if  blocking  occurs. 
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"1 

/*  M00EL1A  - SINGLE  SERVER  QUEUING  MODEL  */ 

/*  WITH  UNIFORMLY  DISTRIBUTED  ARRIVALS  */ 

FACILITY  TRANSMITTER; 

PROCESS  TRANSMIT,  T=10,  R=l; 

START:  IF  TIME  > 3000  THEN  STOP; 

NEW  TRANSACTION  TO  SEND; 

WAIT  360; 

GO  TO  START; 

SEND:  SEIZE  TRANSMITTER; 

WAIT  400; 

CANCEL; 

END; 

/*  MODEL IB  - SINGLE  SERVER  QUEUING  MODEL  */ 

/*  WITH  POISSON  DISTRIBUTED  ARRIVALS  */ 

FACILITY  TRANSMITTER; 

PROCESS  TRANSMIT,  >10,  R=l; 

START:  IF  TIME  > 3000  THEN  STOP; 

WAIT  EXP0NENTIAL(360 ) ; 

NEW  TRANSACTION  TO  START; 

SEIZE  TRANSMITTER; 

WAIT  400; 

CANCEL; 


/*  M0DEL1C  - SINGLE  SERVER/PARAMETERIZED  INPUT  */ 

INTEGER  SIMTIME , INTTIME .SERTIME ; 

FACILITY  TRANSMITTER; 

PROCESS  TRANSMIT,  T =10,  R=l; 

GET  F ILE ( CARD ) LIST(SIMTIME, INTTIME, SERTIME); 

START:  IF  TIME  > SIMTIME  THEN  STOP; 

WAIT  EXPONENTIAL (I NTTIME); 

NEW  TRANSACTION  TO  START; 

SEIZE  TRANSMITTER; 

WAIT  SERTIME; 

CANCEL; 

END; 

/*  M0DEL1D  - SINGLE  SERVER  WITH  PRIORITY  HANDLING  */ 

INTEGER  SIMTIME, INTTIME, SERTIME; 

FACILITY  TRANSMITTER; 

PROCESS  TRANSMIT,  T=1U,  R=I; 

GET  FILE (CARD)  L 1ST ( SIMTIME , INTTIME .SERTIME ) ; 

START:  IF  TIME  > SIMTIME  THEN  STOP; 

WAIT  EXPONENTIAL (INTTIME); 

NEW  TRANSACTION  Tu  START; 

PRIORITY  = 1:8; 

PLIBEGIN; 

PUT  EDIT  ('CARD  RECEIVED  AT  ' .TIME ) (A(17) ,F(6) ) SKIP; 
PLIEND; 

SEIZE  TRANSMITTER; 

WAIT  SERTIME; 

CANCEL; 

END; 
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10  /*  M0DEL1E  - SINGLE  SERVER  QUEUING  MODEL  */ 

20  /*  WITH  PREEMPTION  */ 

30  INTEGER  SIMTIME, INTTIME .SERTIME ; 

40  FACILITY  TRANSMITTER; 

50  PROCESS  TRANSMIT,  T=10,  R=l; 

60  INTEGER  STRENGTH; 

70  GET  F ILE (CARD ) LIST (SIMTIME , INTTIME .SERTIME ) ; 

80  INTERRUPT  = FINISH; 

90  START:  IF  TIME  > SIMTIME  THEN  STOP; 

100  WAIT  EXPONENTIAL (INTTIME); 

110  NEW  TRANSACTION  TO  START; 

120  PRIORITY  = 1:8; 

130  STRENGTH  =1:4; 

140  PLIBEGIN; 

150  PUT  EDIT  ('CARD  RECEIVED  AT  ' ,TIME)(A(17) ,F(6) ) SKIP; 

160  PLIEND; 

170  SEIZE  TRANSMITTER, STRENGTH; 

180  WAIT  SERTIME; 

190  CANCEL; 

2U0  FINISH: 

210  PLIBEGIN; 

220  PUT  EDIT ('PREEMPTION  OCCURRED  AT  '.TIME)  (A(23),F(6))  SKIP; 
230  PLIEND; 

240  CANCEL; 

250  END; 


EXPLANATION  TO  MODEL  IE.  CODE 

STATEMENTS  10,  20.  /*  MODEL  IE  - SINGLE  SERVER  QUEUING  MODEL*/ 

/*  WITH  PREEMPTION  */ 

The  first  two  statements  contain  explanatory  text.  Since  it 
is  bracketted  with  /*  . . . . */  it  will  be  ignored  by  the 

translator. 

STATEMENT  30.  INTEGER  SIMTIME,  INTTIME,  SERTIME; 

This  statement  declares  the  global  variables  SIMTIME, 
INTTIME,  and  SERTIME.  Within  the  model  these  variables  will 
assume  the  following  meaning. 

SIMTIME  = Simulation  time,  the  time  after  which  the 
simulation  is  to  De  terminated. 

INTTIME  = Interarrival  time  for  transactions. 

SERTIME  = Server  time,  the  time  a transaction  will  seize  a 
facility  until  it  is  served. 
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STATEMENT  40.  FACILITY  TRANSMITTER; 


This  statement  declares  one  nonsubscribed  facility  with  the 
name  TRANSMITTER. 

STATEMENT  50.  PROCESS  TRANSMIT,  T=10,  R-l; 

This  statement  declares  the  process  with  the  name  TRANSMIT. 
T=10  specifies  that  not  more  than  10  transactions  will  be  active 
at  any  one  time  during  the  simulation.  An  active  transaction  is 
a transaction  which  has  been  created  and  not  yet  cancelled. 

R=1  specifies  that  no  transaction  will  use  more  than  one 
resource.  During  model  checkout,  these  parameters  should  be  kept 
to  a minimum  to  optimize  cor<*  utilization. 

STATEMENT  60.  INTEGER  STRENGTH; 

This  statement  declares  STRENGTH  as  a local  variable  within 
the  process. 

STATEMENT  70.  GET  FILE(CARD)  LIST(SIMTIME,  INTTIME,  SERTIME); 

This  statement  is  a PL/1  statement  which  has  been  inserted 
into  the  SOL  route  to  read  the  file  named  'CARD'  and  assign  the 
first  three  numerical  values  to  the  global  variables  SIMTIME, 
INTTIME,  SERTIME. 

STATEMENT  80.  INTERRUPT  = FINISH; 

This  statement  specifies  that  any  preempted  transaction  is 
to  be  sent  to  Laoel  'FINISH'. 

STATEMENT  90.  START:  IF  TIME  > SIMTIME  THEN  STOP; 

This  compound  statement,  identified  by  the  label  'START', 
tests  the  global  variable  SIMTIME  against  the  built-in  global 
variable  TIME.  TIME  is  a reserved  word  within  SOL  and  represents 
the  current  time  of  the  simulation.  If  TIME  exceeds  the  value 
for  SIMTIME,  the  simulation  will  be  terminated,  as  specified  by 
the  STOP  statement. 

STATEMENT  100.  WAIT  EXPONENTIAL! INTTIME ) ; 

This  statement  specifies  that  the  transaction  is  to  be 
placed  into  the  wait  queue  for  the  time  specified  by  the  built- 
in  function  EXP.  The  EXP  function  will  sample  a value  from  an 
exponential  distribution  with  the  average  value  INTTIME. 

I i 
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STATEMENT  11U. 


NEW  TRANSACTION  TO  START; 


This  statement  specifies  that  a new  transaction  with  the 
same  local  variables  Is  to  be  created  and  to  be  sent  to  the  label 
'START1.  The  original  transaction  will  continue  to  run  until  It 
encounters  a wait  status.  Then  the  new  transaction  will  start 
executing. 

STATEMENT  120.  PRIORITY  = 1:8; 

This  statement  assigns  a random  Integer  between  1 and  8 to 
the  built-in  local  variable  'PRIORITY'.  The  local  variable 
PRIORITY  is  used  by  the  system  to  resolve  any  conflicts  between 
transactions  requiring  the  same  action  at  the  same  time.  In  this 
case.  It  will  control  the  seizing  of  the  facility  TRANSMITTER  by 
transactions  which  have  entered  a queue  because  the  facility  was 
busy. 

STATEMENT  130.  STRENGTH  « 1:4; 

This  statement  assigns  an  integer  value  between  1 and  4 
to  the  local  variable  STRENGTH. 

STATEMENTS  140  to  160.  PLIBEGIN;  PUT  EDIT  ('CARD  RECEIVED  AT', 

TIME)  ( A(17 ) , F(b) ) SKIP;  PLIEND; 

These  three  statements  represent  a PL/1  block  which 
was  inserted  to  send  a message  to  the  SYSPRINT  file.  The  PL/1 
PUT  statement  has  been  bracketed  by  PLIBEGIN  and  PLIEND.  In  this 
way  the  entire  PL/I  block  is  bypassed  by  the  translator  and 
the  associated  text  Inserted  unaltered. 

STATEMENT  17U.  SEIZE  TRANSMITTER,  STRENGTH; 

One  of  the  following  actions  takes  place: 

a.  If  the  facility  TRANSMITTER  is  not  busy,  the  transaction 
simply  seizes  the  facility  and  marks  it  busy.  An  entry  Is  placed 
Into  the  log  file. 

b.  If  the  facility  is  busy  with  a transaction  of  holding 
strength  equal  to  or  higher  than  the  local  variable  STRENGTH 
of  the  calling  transaction,  the  calling  transaction  enters 
the  wait  queue  for  this  facility. 

c.  If  the  facility  Is  busy  with  a transaction  of  lower 
holding  strength,  this  transaction  Is  preempted  and  sent  to  the 
action  label  FINISH  as  specified  In  the  INTERRUPT  statement. 
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STATEMENT  180.  WAIT  SERTIME; 

The  transaction  encountering  this  statement  will  enter  the 
wait  queue  for  the  period  specified  oy  the  value  of  SERTIME.  The 
next  transaction  in  the  time  queue  will  then  start  executing. 

STATEMENT  190.  CANCEL; 

This  statement  will  cause  all  resources  the  transaction  is 
using  to  be  freed  and  the  transaction  to  be  deactivated. 
Corresponding  entries  are  made  in  the  log  file. 

STATEMENT  200.  FINISH; 

This  is  a simple  label  statement  that  has  been  specified  as 
the  action  label  for  an  interrupt. 

STATEMENTS  210  to  230.  PLIBEGIN ; PUT  EDIT  ('PREEMPTION  OCCURRED 

AT'. TIME)  (A{23) , F(6) ) SKIP;  PLIEND; 

These  three  statements  represent  a PL/I  block,  similar  to 
statements  140  to  160,  which  will  cause  a message  to  be  sent  to 
the  SYSPRINT  file  whenever  a transaction  is  preempted. 

STATEMENT  240.  CANCEL; 

This  statement  will  deactivate  the  transaction. 

STATEMENT  2S0.  END; 

The  END  statement  identifies  the  eno  of  the  process  and  is 
ignored  by  the  transactions. 


/*  M00EL1F  - SINGLE  SERVER  QUEUING  MODEL  */ 

/*  WITH  EXTERNAL  QUEUE  */ 

INTEGER  SIMTIME, INTTIME .SERTIME ; 

FACILITY  TRANSMITTER; 

STORE  1000  QUEUE; 

PROCESS  CONTROL, T=1,R=U; 

GET  FILE(CARD)  LIST(SIMTIME, INTTIME, SERTIME); 

WAIT  SIMTIME; 

STOP; 

END; 

PROCESS  TRANSMIT,  T=10,  R=2; 

INTEGER  STRENGTH; 

INTERRUPT  = FINISH; 

START; 

WAIT  EXPONENTIAL (INTTIME); 

NEW  TRANSACTION  TO  START; 

PRIORITY  = 1:8; 

STRENGTH  * 1:4; 

PUT  EDIT  ('CARD  RECEIVED  AT  ' .TIME ) ( A( 1 7 ) ,F( 6 ) ) SKIP; 

ENTER  QUEUE; 

SEIZE  TRANSMITTER,  STRENGTH; 

WAIT  SERTIME; 

CANCEL* 

FINISH:  PUT  EDIT( 'PREEMPTION  OCCURRED  AT  '.TIME)  (A(23),F(6))  SKIP; 
CANCEL; 

END; 


/*  MOOEL1G  - SINGLE  SERVER  QUEUING  MODEL  WITH  EXTERNAL  QUEUE  */ 
INTEGER  SIMTIME, INTTIME, SERTIME; 

FAC ILITY  TRANSMITTER (S ) .RECEIVER (5 ) ; 

STORE  10U0  SENDQUEUE ( 5 ) , 1000  RECEIVEQUEUE(5); 

PROCESS  CONTROL,  T=l,  R=0; 

GET  FILE(CARD)  LIST(SIMTIME, INTTIME, SERTIME); 

WAIT  SIMTIME; 

STOP; 

END; 

PROCESS  TRANSMIT,  T=10,  R=4; 

INTEGER  STRENGTH , OR IG.DEST .NUMBER ; 

INTERRUPT  = FINISH; 

NUMBER=0; 

START • 

WAIT  EXPONENTIAL (I NTTIME); 

NEW  TRANSACTION  TO  START; 

NUMBER  = NUMBER+1; 

PRIORITY  = 1:8; 

STRENGTH  = 1:4; 

ORIG  =1:5; 

DEST  =1:5; 


PL I BEGIN; 

PUT  EDIT  ('CARD  '.NUMBER,'  RECEIVED  AT  NODE  '.ORIG, 

' AT  TIME  ' ,TTIME)  ( A( 5 ) ,F(4 ) , A( 1 8 ) ,F( 2 ) ,A(9) ,F(6) ) SKIP; 

PLIEND; 

ENTER  SENDQUEUE(ORIG) 
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SE I ZE  TRANSMITTER ( OR I G ) , STRENGTH ; 

ENTER  RECEI VEQUEUE (OEST ) ; 

SEIZE  RECE I VER(DEST), STRENGTH; 

WAIT  SERTIME; 

CANCEL; 

FINISH; 

PLIBEGIN; 

PUT  EDIT ( 'CARD  NUMBER,'  PREEMPTED  AT  TIME  '.TIME) 
( A{5) ,F(4) ,A(19) ,F(6) ) SKIP; 

PLIEND; 

CANCEL; 

END; 


INPUT  PARAMETER  LIST  FOR  STATISTICS.  SOL. DATA ( STATIN ) 

NO 

0, 

NO 

NO 


CLASS! Z)  OUTPUT  OF  STATISTICS  STEP  'SOL(S)'  FOR  MODEL 1G 


NAME  OF  FACILITY 

TIME 

FRACTION  OF  TIME 

IN  USE 

TRANSMITTER 

( 

1) 

20866 

0.0958 

TRANSMITTER 

( 

2) 

20866 

0.1114 

TRANSMITTER 

( 

3) 

20866 

0.1534 

TRANSMITTER 

( 

4) 

20866 

0.1342 

TRANSMITTER 

( 

5) 

20866 

0.2210 

RECEIVER 

( 

1) 

20866 

0.1725 

RECEIVER 

( 

2) 

20866 

0.1279 

RECEIVER 

( 

3) 

20866 

0.0958 

RECEIVER 

( 

4) 

20866 

0.1150 

RECEIVER 

( 

5) 

20866 

0.1725 

NAME  OF 

STORE 

TIME  CAPCTY 

MAX  USD  TOTAL  OCCP 

AVG  UTL 

SENOQUEUE 

( 

1) 

20866 

1000 

1 

2000 

0.0001 

SENDQUEUE 

( 

2) 

20866 

1000 

2 

2324 

0.0001 

SENDQUEUE 

( 

3) 

20866 

1000 

1 

3200 

0.0002 

SENOQUEUE 

( 

4) 

20866 

1000 

1 

2800 

0.0001 

SENDQUEUE 

! 

6) 

20866 

1000 

2 

4933 

0.0002 

RECE I VEQUEUE! 

1) 

20866 

1000 

2 

3655 

0.0002 

RECE I VEQUEUE! 

2) 

20866 

1000 

1 

2669 

0.0001 

RECE I VEQUEUE! 

3) 

20866 

1000 

1 

2000 

0.0001 

RECE I VEQUEUE! 

4) 

20866 

1000 

1 

2400 

0.0001 

RECEIVEQUF'IE! 

5) 

20866 

1000 

2 

4222 

0.0002 
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CLASS (Y ) OUTPUT  OF  MODEL1G 


CARD 

1 

RECEIVED 

AT 

NODE 

1 

AT 

TIME 

470 

CARD 

1 

RECEIVED 

AT 

NODE 

3 

AT 

TIME 

716 

CARD 

1 

RECEIVED 

AT 

NODE 

5 

AT 

TIME 

962 

CARD 

1 

RECEIVED 

AT 

NODE 

5 

AT 

TIME 

1051 

CARD 

1 

RECEIVED 

AT 

NODE 

2 

AT 

TIME 

1185 

CARD 

1 

RECEIVED 

AT 

NODE 

4 

AT 

TIME 

1525 

CARD 

1 

RECEIVED 

AT 

NODE 

4 

AT 

TIME 

2261 

CARD 

1 

RECEIVED 

AT 

NODE 

5 

AT 

TIME 

3501 

CARD 

1 

RECEIVED 

AT 

NODE 

4 

AT 

TIME 

3855 

CARD 

1 

RECEIVED 

AT 

NODE 

3 

AT 

TIME 

4066 

CARD 

1 

RECEIVED 

AT 

NODE 

1 

AT 

TIME 

4601 

CARD 

1 

RECEIVED 

AT 

NODE 

3 

AT 

TIME 

5137 

CARD 

1 

RECEIVED 

AT 

NODE 

3 

AT 

TIME 

5987 

CARD 

1 

RECEIVED 

AT 

NODE 

5 

AT 

TIME 

6319 

CARD 

1 

RECEIVED 

AT 

NODE 

3 

AT 

TIME 

6869 

CARD 

1 

RECEIVED 

AT 

NODE 

5 

AT 

TIME 

7065 

CARD 

1 

RECEIVED 

AT 

NODE 

5 

AT 

TIME 

9217 

CARD 

1 

RECEIVED 

AT 

NODE 

2 

AT 

TIME 

9835 

CARD 

1 

RECEIVED 

AT 

NODE 

5 

AT 

TIME 

9957 

CARD 

1 

RECEIVED 

AT 

NODE 

2 

AT 

TIME 

10104 

CARD 

1 

RECEIVED 

AT 

NODE 

3 

AT 

TIME 

10282 

CARD 

1 

RECEIVED 

AT 

NODE 

3 

AT 

TIME 

11004 

CARD 

1 

RECEIVED 

AT 

NODE 

2 

AT 

TIME 

11465 

CARD 

1 

RECEIVED 

AT 

NODE 

4 

AT 

TIME 

12102 

CARD 

1 

RECEIVED 

AT 

NODE 

2 

AT 

TIME 

12447 

CARD 

1 

RECEIVED 

AT 

NODE 

1 

AT 

TIME 

13239 

CARO 

1 

RECEIVED 

AT 

NODE 

1 

AT 

TIME 

14493 

CARD 

1 

RECEIVED 

AT 

NODE 

4 

AT 

TIME 

14932 

CARD 

1 

RECEIVED 

AT 

NODE 

5 

AT 

TIME 

14933 

CARD 

1 

RECEIVED 

AT 

NODE 

4 

AT 

TIME 

15340 

CARD 

1 

RECEIVED 

AT 

NODE 

3 

AT 

TIME 

15512 

CARD 

1 

RECEIVED 

AT 

NODE 

4 

AT 

TIME 

16097 

CARD 

1 

RECEIVED 

AT 

NODE 

5 

AT 

TIME 

16307 

SIMULATION  TERMINATED  - 

I/O  ERROR 

CONTENTS  OF  FILE  SOL. DATA (GOIN ) : 200U,  500,  400 
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/*  M0DEL1H  - 5-NODE  FULLY  CONNECTED  NETWORK  WITH  BLOCKED  LINKS  */ 
INTEGER  SIMTIME , INTTIME .SERTIME ,NUM; 

PLIBEGIN; 

DCL  CONN(5 ,5)  FIXED  BIN(31); 

PLIEND; 

FACILITY  TRANSMITTER (S), RECEIVER (5); 

STORE  1UUO  SENDQUEUE(b),  1UOO  RECE I VEQUEUE ( 5 ) , 8 LINK(IU); 

PROCESS  CONTROL,  T=l,  R=0; 

GET  FILE (CARD)  LIST(SIMTIME, INTTIME, SERTIME, CONN); 

WAIT  SIMTIME; 

STOP; 

END; 

PROCESS  TRANSMIT,  T=50,  R=5; 

I NTEGER  STRENGTH , OR IG , DEST , NUMB ER ; 

INTERRUPT  = FINISH; 

NUM=0; 

START: 

WAIT  EXPONENTIAL (I NTTIME); 

NEW  TRANSACTION  TO  START; 

NUMBER ,NUM  = NUM+1; 

PRIORITY  = 1:8; 

STRENGTH  = 1:4; 

ORIG  =1:5; 

RET:  DEST  =1:5; 

IF  DEST  = ORIb  THEN  GO  TO  RET; 

PUT  EDIT  ('CARD  ', NUMBER,’  RECEIVED  AT  NODE  '.ORIG,'  AT  TIME  ', 
TIME  ',  TO  =' ,DEST ) ( A(b ) ,F(4 ) ,A(18) ,F(2 ) ,A(9) ,F(6) ,A(5 ) ,F(2 ) ) SKIP; 
ENTER  SENDgUEUE(ORIb); 

SEIZE  TRANSMITTER (ORIG ) , STRENGTH ; 

ENTER  LINK (CONN (ORIG, DEST ) ) ; 

ENTER  RECEIVEQUEUE(DEST); 

SEIZE  RECEIVER (DEST), STRENGTH; 

WAIT  SERTIME; 

CANCEL; 

FINISH:  PUT  EDIT ( 'CARD  '.NUMBER,'  PREEMPTED  AT  TIME  '.TIME) 

( A(5 ) ,F(4 ) ,A( 19) ,F(6 ) ) SKIP; 

CANCEL; 

END; 


Input  Dataset  SOL.DATA(GOIN): 

20000,100,500, 

0,1, 2, 3, 4, 

1.0.  5. 6. 7, 

2,5vO,B,9, 

3.6.8.0. 1,, 

4.7.9.10.0, 
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